Stratégies de mise en cache frontend : cache HTTP et cache Service Worker

Dans le monde du développement web, l'optimisation de la performance des sites est primordiale. Un site lent peut frustrer les utilisateurs, augmenter les taux de rebond et, au final, avoir un impact négatif sur votre entreprise. La mise en cache, une technique consistant à stocker et réutiliser des ressources précédemment récupérées, joue un rôle vital dans l'amélioration de la vitesse du site et la réduction de la charge du serveur. Cet article offre un aperçu complet de deux stratégies clés de mise en cache frontend : la mise en cache HTTP et la mise en cache par Service Worker.

Comprendre les principes fondamentaux de la mise en cache

La mise en cache consiste à stocker des copies de ressources, telles que le HTML, le CSS, le JavaScript, les images et d'autres actifs, plus près de l'utilisateur. Lorsqu'un utilisateur demande une ressource, le navigateur ou un intermédiaire de mise en cache vérifie d'abord si une copie en cache est disponible. Si c'est le cas (un « cache hit »), la ressource est servie depuis le cache, évitant un aller-retour vers le serveur d'origine. Cela réduit considérablement la latence et améliore les temps de chargement.

Il existe plusieurs niveaux de mise en cache, y compris le cache du navigateur, le cache proxy et le cache côté serveur. Cet article se concentre sur la mise en cache frontend, en particulier sur la manière de tirer parti du cache HTTP intégré du navigateur et du cache plus avancé des Service Workers.

Mise en cache HTTP : exploiter les capacités du navigateur

La mise en cache HTTP est le mécanisme intégré du navigateur pour stocker et récupérer des ressources. Elle est contrôlée par des en-têtes HTTP envoyés par le serveur dans la réponse à une requête. Ces en-têtes fournissent des instructions au navigateur sur la durée de mise en cache d'une ressource et les conditions dans lesquelles elle doit être considérée comme valide.

En-têtes de cache HTTP clés

• Cache-Control : C'est l'en-tête le plus important pour contrôler la mise en cache HTTP. Il vous permet de spécifier diverses directives, telles que :
• max-age=secondes : Spécifie la durée maximale pendant laquelle une ressource est considérée comme fraîche. Passé ce délai, le navigateur doit revalider le cache auprès du serveur. Exemple : Cache-Control: max-age=3600 (mise en cache pour 1 heure).
• s-maxage=secondes : Similaire à max-age, mais s'applique spécifiquement aux caches partagés comme les CDN. Exemple : Cache-Control: max-age=3600, s-maxage=86400 (mise en cache pendant 1 heure dans le navigateur, 1 jour dans un CDN).
• public : Indique que la réponse peut être mise en cache par n'importe quel cache, y compris les caches partagés.
• private : Indique que la réponse ne peut être mise en cache que par le navigateur et non par les caches partagés. Utile pour les données spécifiques à l'utilisateur.
• no-cache : Force le navigateur à revalider le cache auprès du serveur avant de l'utiliser, même s'il est encore frais.
• no-store : Empêche le navigateur de mettre en cache la réponse.
• Expires : Un ancien en-tête qui spécifie une date et une heure absolues d'expiration de la ressource. Cache-Control supplante généralement Expires si les deux sont présents. Exemple : Expires: Wed, 21 Oct 2024 07:28:00 GMT
• ETag : Un identifiant unique pour une version spécifique d'une ressource. Le navigateur envoie l'ETag dans l'en-tête de requête If-None-Match lors de la revalidation. Si la ressource n'a pas changé, le serveur renvoie une réponse 304 Not Modified, indiquant que le navigateur peut utiliser la version en cache.
• Last-Modified : Indique la dernière fois que la ressource a été modifiée. Le navigateur envoie la date Last-Modified dans l'en-tête de requête If-Modified-Since lors de la revalidation. Similaire à ETag, le serveur peut renvoyer une réponse 304 Not Modified si la ressource n'a pas changé.

Exemples pratiques de mise en cache HTTP

Exemple 1 : Mise en cache d'actifs statiques (images, CSS, JavaScript) :

Pour les actifs statiques qui changent rarement, vous pouvez définir une valeur max-age longue :

            Cache-Control: public, max-age=31536000  

            

              
                Copy
              
            
          

Cela indique au navigateur de mettre la ressource en cache pendant un an (31 536 000 secondes) et qu'elle peut être mise en cache par n'importe quel cache (public).

Exemple 2 : Mise en cache de contenu dynamique avec revalidation :

Pour le contenu dynamique qui change plus fréquemment, vous pouvez utiliser no-cache avec ETag ou Last-Modified pour la revalidation :

            Cache-Control: no-cache, must-revalidate
ETag: "unique-etag-value"

            

              
                Copy
              
            
          

Cela force le navigateur à revalider le cache auprès du serveur avant de l'utiliser. Le serveur peut alors utiliser l'ETag pour déterminer si la ressource a changé et renvoyer une réponse 304 Not Modified si ce n'est pas le cas.

Exemple 3 : Servir des actifs versionnés :

Une pratique courante consiste à inclure un numéro de version dans le nom de fichier de l'actif (par ex., style.v1.css). Lorsque l'actif change, vous mettez à jour le numéro de version, forçant le navigateur à télécharger la nouvelle version. Cela vous permet de mettre en cache les actifs de manière agressive sans vous soucier de servir du contenu obsolète.

Meilleures pratiques pour la mise en cache HTTP

• Utiliser un CDN : Les réseaux de diffusion de contenu (CDN) distribuent le contenu de votre site web sur plusieurs serveurs géographiquement plus proches des utilisateurs. Cela réduit la latence et améliore les temps de chargement, en particulier pour les utilisateurs dans différentes parties du monde. Les CDN populaires incluent Cloudflare, Akamai et Amazon CloudFront. Un site web au Japon chargeant des images depuis un serveur en Europe bénéficiera grandement d'un CDN avec des serveurs en Asie.
• Tirer parti de la mise en cache du navigateur : Configurez votre serveur pour envoyer les en-têtes de cache HTTP appropriés pour toutes vos ressources.
• Utiliser des techniques de "cache busting" : Employez des techniques comme le versionnement ou les paramètres de requête pour forcer les navigateurs à télécharger les ressources mises à jour lorsqu'elles changent.
• Surveiller les performances du cache : Utilisez les outils de développement du navigateur et les analyses côté serveur pour surveiller les taux de réussite du cache et identifier les domaines à améliorer.

Cache Service Worker : contrôle avancé et capacités hors ligne

Les Service Workers sont des fichiers JavaScript qui s'exécutent en arrière-plan, séparément du thread principal du navigateur. Ils agissent comme un proxy entre le navigateur et le réseau, vous permettant d'intercepter les requêtes réseau et de mettre en œuvre des stratégies de mise en cache avancées.

Les Service Workers sont une technologie clé derrière les Progressive Web Apps (PWA), permettant des fonctionnalités comme l'accès hors ligne, les notifications push et la synchronisation en arrière-plan.

Comment fonctionnent les Service Workers

1. Enregistrement : Le Service Worker est enregistré par votre page web.
2. Installation : Le Service Worker est installé dans le navigateur. C'est généralement là que vous pré-mettez en cache les ressources essentielles.
3. Activation : Le Service Worker devient actif et commence à contrôler les requêtes réseau pour les pages relevant de son champ d'action.
4. Interception : Le Service Worker intercepte les requêtes réseau et peut choisir de servir les ressources depuis le cache, de les récupérer depuis le réseau, ou même de créer une réponse synthétique.

API clés des Service Workers pour la mise en cache

• API Cache : Fournit un mécanisme pour stocker et récupérer les réponses mises en cache. Elle vous permet de créer des caches nommés et d'ajouter, de mettre à jour et de supprimer des entrées.
• API Fetch : Utilisée pour effectuer des requêtes réseau depuis le Service Worker.
• addEventListener('install', ...) : Le gestionnaire d'événements qui s'exécute lorsque le service worker est installé pour la première fois. Il est couramment utilisé pour pré-mettre en cache les actifs importants.
• addEventListener('activate', ...) : Le gestionnaire d'événements qui s'exécute lorsque le service worker devient actif. Il est couramment utilisé pour nettoyer les anciens caches.
• addEventListener('fetch', ...) : Le gestionnaire d'événements qui intercepte les requêtes réseau. C'est là que réside la logique de mise en cache.

Stratégies de mise en cache avec les Service Workers

Les Service Workers vous permettent de mettre en œuvre diverses stratégies de mise en cache adaptées à différents types de ressources et de conditions réseau. Voici quelques stratégies courantes :

• Cache d'abord (Cache First) : Servir toujours la ressource depuis le cache si elle est disponible. Si elle n'est pas dans le cache, la récupérer depuis le réseau et la stocker dans le cache pour une utilisation future. C'est idéal pour les actifs statiques qui changent rarement.
• Réseau d'abord (Network First) : Toujours essayer de récupérer la ressource depuis le réseau en premier. Si le réseau est disponible, servir la ressource et mettre à jour le cache. Si le réseau n'est pas disponible, servir la ressource depuis le cache. Cela convient au contenu dynamique qui doit être aussi à jour que possible.
• Cache, puis réseau (Cache, then Network) : Servir la ressource depuis le cache immédiatement tout en récupérant simultanément la dernière version depuis le réseau. Mettre à jour le cache avec la nouvelle version lorsqu'elle arrive. Cela offre un chargement initial rapide et garantit que l'utilisateur obtiendra finalement le contenu le plus récent.
• Stale-While-Revalidate : Servir la ressource depuis le cache immédiatement. En arrière-plan, récupérer la dernière version depuis le réseau et mettre à jour le cache. La prochaine fois que la ressource sera demandée, la version mise à jour sera servie. Cette stratégie offre un chargement initial rapide et garantit que l'utilisateur obtient toujours la version la plus récente à terme, sans bloquer la requête initiale.
• Réseau seulement (Network Only) : Toujours récupérer la ressource depuis le réseau. Ne jamais utiliser le cache. C'est approprié pour les ressources qui ne devraient jamais être mises en cache, comme les données utilisateur sensibles.
• Cache seulement (Cache Only) : Toujours servir la ressource depuis le cache. Ne jamais la récupérer depuis le réseau. C'est utile pour les scénarios où vous voulez vous assurer que la ressource est toujours disponible hors ligne.

Exemples pratiques de mise en cache avec un Service Worker

Exemple 1 : Stratégie Cache First pour les actifs statiques :

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // Succès du cache - retourner la réponse
        if (response) {
          return response;
        }

        // Pas en cache - récupérer depuis le réseau
        return fetch(event.request).then(
          response => {
            // Vérifier si nous avons reçu une réponse valide
            if (!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // IMPORTANT : Cloner la réponse. Une réponse est un flux (stream)
            // et comme nous voulons que le navigateur consomme la réponse
            // ainsi que le cache, nous devons
            // la cloner.
            const responseToCache = response.clone();

            caches.open('my-site-cache')
              .then(cache => {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
  );
});

            

              
                Copy
              
            
          

Cet extrait de code démontre la stratégie Cache First. Le Service Worker vérifie d'abord si la ressource demandée est disponible dans le cache. Si c'est le cas, il sert la ressource depuis le cache. Sinon, il récupère la ressource du réseau, la stocke dans le cache, puis la sert au navigateur.

Exemple 2 : Stratégie Stale-While-Revalidate pour le contenu dynamique :

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.open('my-site-cache').then(cache => {
      return cache.match(event.request).then(response => {
        const fetchPromise = fetch(event.request).then(networkResponse => {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
        return response || fetchPromise;
      })
    })
  );
});

            

              
                Copy
              
            
          

Cet extrait de code démontre la stratégie Stale-While-Revalidate. Le Service Worker sert la ressource depuis le cache immédiatement. En arrière-plan, il récupère la dernière version depuis le réseau et met à jour le cache. La prochaine fois que la ressource sera demandée, la version mise à jour sera servie.

Meilleures pratiques pour la mise en cache avec un Service Worker

• Utiliser une bibliothèque de stratégies de mise en cache : Des bibliothèques comme Workbox simplifient le développement des Service Workers en fournissant des stratégies de mise en cache et des utilitaires pré-construits. Cela peut vous faire gagner du temps et des efforts et garantir que votre logique de mise en cache est robuste et fiable.
• Gérer les versions du cache : Lorsque vous mettez à jour votre Service Worker, vous devez invalider l'ancien cache et en créer un nouveau. Cela évite de servir des ressources obsolètes. Utilisez l'événement activate pour nettoyer les anciens caches.
• Gérer les erreurs avec élégance : Mettez en œuvre une gestion des erreurs pour gérer avec élégance les échecs réseau et les absences du cache. Fournissez un contenu de secours ou informez l'utilisateur que la ressource n'est pas disponible.
• Tester de manière approfondie : Testez votre logique de mise en cache du Service Worker dans différentes conditions de réseau et environnements de navigateur pour vous assurer qu'elle fonctionne comme prévu. Utilisez les outils de développement du navigateur pour inspecter le cache et surveiller les requêtes réseau.
• Prendre en compte l'expérience utilisateur : Concevez votre stratégie de mise en cache en gardant à l'esprit l'expérience utilisateur. Fournissez un retour à l'utilisateur lorsqu'une ressource est récupérée depuis le réseau ou le cache. Évitez de servir du contenu obsolète pendant trop longtemps.

Comparaison entre le cache HTTP et le cache Service Worker

Bien que la mise en cache HTTP et la mise en cache par Service Worker visent toutes deux à améliorer les performances du site web, elles diffèrent par leurs capacités et leurs cas d'utilisation.

Considérations globales pour la mise en cache

Lors de la mise en œuvre de stratégies de mise en cache pour une audience mondiale, tenez compte des points suivants :

• Conditions du réseau : Les utilisateurs de différentes régions peuvent connaître des vitesses et une fiabilité de réseau variables. Adaptez votre stratégie de mise en cache pour tenir compte de ces différences. Par exemple, les utilisateurs dans des zones avec un accès internet peu fiable bénéficieront grandement d'un support hors ligne robuste.
• Couverture du CDN : Choisissez un CDN avec un réseau mondial de serveurs pour vous assurer que votre contenu est livré rapidement aux utilisateurs de toutes les régions. Vérifiez que le CDN a des Points de Présence (PoP) dans les régions critiques pour votre audience.
• Confidentialité des données : Soyez conscient des réglementations sur la confidentialité des données dans différents pays lors de la mise en cache de données spécifiques à l'utilisateur. Assurez-vous de vous conformer aux lois comme le RGPD et le CCPA.
• Langue et localisation : Envisagez de mettre en cache des versions localisées de votre site web pour offrir une meilleure expérience utilisateur aux utilisateurs de différentes langues et régions.
• Invalidation du cache : Mettez en œuvre une stratégie d'invalidation de cache fiable pour vous assurer que les utilisateurs obtiennent toujours le contenu le plus récent, même s'il change fréquemment. Portez une attention particulière aux mises à jour de contenu localisé.

Conclusion

La mise en cache frontend est une technique essentielle pour optimiser les performances des sites web et améliorer l'expérience utilisateur. En tirant parti de la mise en cache HTTP et de la mise en cache par Service Worker, vous pouvez réduire considérablement les temps de chargement, diminuer la charge du serveur et fournir un accès hors ligne au contenu de votre site web. Examinez attentivement les besoins spécifiques de votre site et votre public cible lors du choix et de la mise en œuvre de stratégies de mise en cache. En adoptant les meilleures pratiques et en surveillant continuellement les performances de votre mise en cache, vous pouvez vous assurer que votre site web offre une expérience rapide et fiable aux utilisateurs du monde entier.